Reserve airline staffing levels

ABSTRACT

A crew planning system includes a demand forecasting module and an optimization module. The system forecasts anticipated reserve demand levels, and determines suitable reserve staffing approaches to meet anticipated reserve demand. The forecasting is based upon probabilistic distribution models which take into account variability associated with reserve demand for a particular day. Via use of the crew planning system, reserve staffing expenses may be reduced and/or reserve demand may be met with a higher degree of probability.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, claims priority to and thebenefit of, U.S. Ser. No. 13/793,049, filed Mar. 11, 2013, entitled“RESERVE FORECASTING SYSTEMS AND METHODS FOR AIRLINE CREW PLANNING ANDSTAFFING”, the contents of which are incorporated herein by reference intheir entirety for all purposes.

TECHNICAL FIELD

The present disclosure generally relates to forecasting, and moreparticularly, to analysis methods and tools suitable for use in crewplanning and staffing.

BACKGROUND

Today, airlines and other human-resource intensive businesses facecostly challenges associated with crew shortfalls. These shortfalls canresult from factors such as schedule disruptions, unusually high sickcalls, etc. When an airline falls short of crew reserves to cover crewabsences, the airline often must cancel the flights, resulting insignificant cost to the airline and inconvenience to the passengers. Onthe other hand, crew reserves are a significant expense for anenterprise. Accordingly, improved approaches for crew planning, reserveforecasting, and/or the like remain desirable.

SUMMARY

In an embodiment, a method comprises: forecasting, by a processor forcrew planning, a daily reserve demand level for each day in a first timeperiod; optimizing, by the processor, a reserve staffing model togenerate a reserve staffing level for each day in the first time period;and evaluating, by the processor, the result of the reserve staffingmodel for each day in the first time period to determine reservestaffing results information.

In another embodiment, a non-transitory computer-readable storage mediumhas computer-executable instructions stored thereon that, in response toexecution by a processor for crew planning, cause the processor toperform operations comprising: forecasting, by the processor, a dailyreserve demand level for each day in a first time period; optimizing, bythe processor, a reserve staffing model to generate a reserve staffinglevel for each day in the first time period; and evaluating, by theprocessor, the result of the reserve staffing model for each day in thefirst time period to determine reserve staffing results information.

BRIEF DESCRIPTION OF THE DRAWINGS

With reference to the following description, appended claims, andaccompanying drawings:

FIG. 1 is a block diagram illustrating exemplary crew planning systemcomponents, in accordance with various embodiments;

FIG. 2A illustrates an exemplary graph of reserve demand, in accordancewith various embodiments;

FIG. 2B illustrates an exemplary graph of reserve demand, reflectingstatistical distribution of reserve demand on a daily basis, inaccordance with various embodiments;

FIG. 2C illustrates an exemplary method for crew planning, in accordancewith various embodiments;

FIG. 2D illustrates a portion of an exemplary method for crew planning,in accordance with various embodiments;

FIG. 2E illustrates an exemplary method for crew planning, in accordancewith various embodiments;

FIG. 2F illustrates an exemplary cost/risk trade-off relationship inaccordance with various embodiments;

FIG. 3A illustrates an exemplary probability distribution, in accordancewith various embodiments;

FIG. 3B illustrates an exemplary cumulative distribution function, inaccordance with various embodiments; and

FIG. 4 illustrates results of an exemplary crew planning system, inaccordance with various embodiments.

DETAILED DESCRIPTION

The following description is of various embodiments only, and is notintended to limit the scope, applicability or configuration of thepresent disclosure in any way. Rather, the following description isintended to provide a convenient illustration for implementing variousembodiments including the best mode. As will become apparent, variouschanges may be made in the function and arrangement of the elementsdescribed in these embodiments without departing from the scope of thepresent disclosure or appended claims.

For the sake of brevity, conventional techniques for data management,computer networking, software application development, forecasting, crewplanning, operations management, statistical analysis, and other aspectsof exemplary systems and methods (and components thereof) and/or thelike, may not be described in detail herein. Furthermore, the connectinglines shown in various figures contained herein are intended torepresent exemplary functional relationships and/or physical orcommunicative couplings between various elements. It should be notedthat many alternative or additional functional relationships or physicalor communicative connections may be present in a practical crew planningsystem.

Airlines continually face challenges associated with the efficientplanning, scheduling and utilization of their flight and cabin crews. Inaddition to regular line-holders (i.e., crew members scheduled to workon a particular date), many airlines maintain significant reservestaffing levels to cover unplanned sick employees and no-shows, meetcontractual obligations, and operate smoothly. When an airline does nothave sufficient reserves to cover the crew absences, the airline usuallymust cancel flights, at significant cost to the airline andinconvenience to the passengers.

Prior approaches to reserve staffing employed only deterministicapproximations to estimate and plan for reserve crew staffing levels.Such estimates typically use static multipliers based on peakline-holder crew requirements to set reserve crew levels. For example,most carriers use historical peak reserve usage to calibrate themultipliers used to set reserve staffing levels. As a result, mostcarriers treat the reserve crew planning and scheduling problem as adeterministic problem that simply represents a safety margin over thenumber of line holders needed to operate the published flight schedule.

In general, most carriers today approach crew pairing, planning andscheduling as a deterministic process due to the fact that they assume afixed planned flight schedule. This assumption is reasonable, given thatthis process focuses on the creation and publications of crew rosters orbidlines for the bidding process by pilots and flight attendants.However, this approach is also limited and incomplete.

Typical crew planning processes in the airline industry take one of twopopular forms: 1) a standard bidline process, or 2) preferentialbidding. A standard bidline schedule represents a process in which crew(for example, pilots and flight attendants) bid on contractuallyfeasible bidlines based on seniority. In contrast, preferential biddingallows individual crew members (either pilots or flight attendants) toinfluence their flight schedules by submitting personal preferencesassociated with their desired work schedule as inputs to the bidlinegeneration process. Using these preferences, the airline builds bidlinesthat try to meet these preferences and generates monthly work/flightschedules for each line holder required to cover the flight schedule.

In contrast, features of the present disclosure can reshape the wayorganizations plan for and/or allocate human resources, for exampleairline crew members. Prior approaches to crew planning, for exampleapproaches to reserve forecasting, may generate excessive reserve levels(i.e., more reserves are provided than are needed), leading tounnecessary costs. Prior approaches can also lead to insufficientreserve levels, leading to cancelled flights, reduced revenue, andtoward the airline.

In accordance with principles of the present disclosure, crew planningsystems and methods enable improved reserve demand forecasting. Invarious embodiments, rather than applying a simple deterministicapproach, exemplary crew planning systems and methods are configured toincorporate probabilistic metrics of risk. For example, in variousembodiments, a crew planning system incorporates probabilistic metricsof risk selected by airline crew planning personnel.

While the present disclosure discusses airlines, flights, pilots, flightattendants, and so forth for purposes of convenience and illustration,one of skill in the art will appreciate that the forecasting methods,systems, and tools disclosed herein are broadly applicable, for exampleto any transportation industry, such as buses, cruise ships, passengertrains, and the like, and more generally to any industry whereincontingency staffing is applied.

Various embodiments of principles of the present disclosure employforecasting, statistical analysis and/or optimization techniques. Formore information regarding such techniques refer to, for example: “TheTheory and Practice of Revenue Management” (International Series inOperations Research & Management Science) by Kalyan T. Talluri andGarrett J. van Ryzin; “Using Multivariate Statistics (5th Edition)” byBarbara G. Tabachnick and Linda S. Fidell; and “Introduction toOperations Research” by Friedrich S. Hiller and Gerald J. Lieberman,McGraw-Hill 7th edition, Mar. 22, 2002; the contents of which are eachhereby incorporated by reference in their entireties.

In various embodiments, exemplary crew planning systems include a userinterface (“UI”), software modules, logic engines, various databases,interfaces to systems and tools, and/or computer networks. Whileexemplary crew planning systems may contemplate upgrades orreconfigurations of existing processing systems, changes to existingdatabases and system tools are not necessarily required by principles ofthe present disclosure.

The benefits provided by principles of the present disclosure include,for example, reduced flight cancellations, increased forecastingaccuracy, improved characterization of staffing risks, lower payrollcosts, increased employee utilization, increased customer good will,increased planning and operational efficiency, increased employeemorale, and the like. For example, a crew planning organization benefitsfrom improved forecasting accuracy and resulting decreased payrollexpenses. Customers benefit from reduced flight cancellations arisingfrom insufficient crew reserves.

As used herein, an “entity” may include any individual, softwareprogram, business, organization, government entity, web site, system,hardware, and/or any other entity. A “user” may include any entity thatinteracts with a system and/or participates in a process.

Turning now to FIG. 1, in accordance with various embodiments, a user105 may perform tasks such as requesting, retrieving, receiving,updating, analyzing and/or modifying data. User 105 may also performtasks such as initiating, manipulating, interacting with or using asoftware application, tool, module or hardware, and initiating,receiving or sending a communication. User 105 may interface withInternet server 125 via any communication protocol, device or methoddiscussed herein, known in the art, or later developed. User 105 may be,for example, a member of a crew planning organization, a member of anoperations research or systems analysis organization, a downstreamsystem, an upstream system, a third-party system, a systemadministrator, and/or the like.

In various embodiments, a system 101 may include a user 105 interfacingwith a crew planning system 115 by way of a client 110. Crew planningsystem 115 may be a partially or fully integrated system comprised ofvarious subsystems, modules and databases. Client 110 comprises anyhardware and/or software suitably configured to facilitate entering,accessing, requesting, retrieving, updating, analyzing and/or modifyingdata. The data may include operational data (e.g., schedules, resources,routes, operational alerts, weather, etc.), human resource data (forexample, on-duty and off-duty days for pilots and flight attendants),passenger data, cost data, forecasts, historical data, verificationdata, asset (e.g., airplane) data, inventory (e.g., airplane seat) data,legal/regulatory data, authentication data, demographic data,transaction data, or any other suitable information discussed herein.

Client 110 includes any device (e.g., a computer), which communicates,in any manner discussed herein, with crew planning system 115 via anynetwork or protocol discussed herein. Browser applications compriseInternet browsing software installed within a computing unit or systemto conduct online communications and transactions. These computing unitsor systems may take the form of personal computers, mobile phones,personal digital assistants, mobile email devices, laptops, notebooks,hand-held computers, portable computers, kiosks, and/or the like.Practitioners will appreciate that client 110 may or may not be indirect contact with crew planning system 115. For example, client 110may access the services of crew planning system 115 through anotherserver, which may have a direct or indirect connection to Internetserver 125. Practitioners will further recognize that client 110 maypresent interfaces associated with a software application (e.g., SASanalytic software) or module that are provided to client 110 viaapplication graphical user interfaces (GUIs) or other interfaces and arenot necessarily associated with or dependent upon Internet browsers orinternet specific protocols.

User 105 may communicate with crew planning system 115 through afirewall 120, for example to help ensure the integrity of crew planningsystem 115 components. Internet server 125 may include any hardwareand/or software suitably configured to facilitate communications betweenthe client 110 and one or more crew planning system 115 components.

Firewall 120, as used herein, may comprise any hardware and/or softwaresuitably configured to protect crew planning system 115 components fromusers of other networks. Firewall 120 may reside in varyingconfigurations including stateful inspection, proxy based and packetfiltering, among others. Firewall 120 may be integrated as softwarewithin Internet server 125, any other system 101 component, or mayreside within another computing device or may take the form of astandalone hardware component.

Authentication server 130 may include any hardware and/or softwaresuitably configured to receive authentication credentials, encrypt anddecrypt credentials, authenticate credentials, and/or grant accessrights according to pre-defined privileges associated with thecredentials. Authentication server 130 may grant varying degrees ofapplication and/or data level access to users based on informationstored within authentication database 135 and user database 140.Application server 142 may include any hardware and/or software suitablyconfigured to serve applications and data to a connected client 110.

In accordance with various embodiments, crew planning system 115 isusable to forecast reserve crew demand, manage crew staffing strategy,evaluate risk associated with a particular crew staffing strategy,generate inputs to other forecasting systems, and/or the like.Continuing to reference FIG. 1, crew planning system 115 allowscommunication with central data repository (CDR) 150, and with variousother databases, tools, UIs and systems, for example external systemsand databases 160. Such systems include, for example, airline schedulingsystems, passenger booking and reservations systems, human resourcesystems, revenue management systems, inventory systems, and/or the like.

Crew planning system 115 components may be interconnected andcommunicate with one another to allow for a completely integrated crewplanning system. In various embodiments, crew planning system 115formulates reserve demand forecast models and associated expense and/orrevenue consequences at the flight level, day level, etc. Crewscheduling systems may generate bidlines and/or otherwise make staffingdecisions based at least in part upon the output of crew planning system115.

In various embodiments, crew planning system 115 modules (e.g., reserveforecasting module 145 and/or optimization module 147) are softwaremodules configured to enable online functions such as sending andreceiving messages, receiving query requests, configuring responses,dynamically configuring user interfaces, requesting data, receivingdata, displaying data, executing complex processes, calculations,forecasts, mathematical techniques, workflows and/or algorithms,prompting user 105, verifying user responses, authenticating the user,initiating crew planning system 115 processes, initiating other softwaremodules, triggering downstream systems and processes, encrypting anddecrypting, and/or the like. Additionally, crew planning system 115modules may include any hardware and/or software suitably configured toreceive requests from client 110 via Internet server 125 and applicationserver 142.

Crew planning system 115 modules may be further configured to processrequests, execute transactions, construct database queries, and/orexecute queries against databases within system 101 (e.g., central datarepository (“CDR”) 150), external data sources and/or temporarydatabases. In various embodiments, one or more crew planning system 115modules may be configured to execute application programming interfacesin order to communicate with a variety of messaging platforms, such asemail systems, wireless communications systems, mobile communicationssystems, multimedia messaging service (“MMS”) systems, short messagingservice (“SMS”) systems, and the like.

Crew planning system 115 modules may be configured to exchange data withother systems and application modules, for example, a scheduling systemthat generates monthly work/flight schedules for line holders in orderto cover a particular airline flight schedule, a flight schedule system,a crew bid system, and/or the like. In various embodiments, crewplanning system 115 modules may be configured to interact with othersystem 101 components to perform complex calculations, retrieveadditional data, format data into reports, create XML representations ofdata, construct markup language documents, construct, define or controlUIs, and/or the like. Moreover, crew planning system 115 modules mayreside as standalone systems or tools or may be incorporated with theapplication server 142 or any other crew planning system 115 componentas program code. As one of ordinary skill in the art will appreciate,crew planning system 115 modules may be logically or physically dividedinto various subcomponents, such as a workflow engine configured toevaluate predefined rules and to automate processes.

In addition to the components described above, crew planning system 115may further include one or more of the following: a host server or othercomputing systems including a processor for processing digital data; amemory coupled to the processor for storing digital data; an inputdigitizer coupled to the processor for inputting digital data; anapplication program stored in the memory and accessible by the processorfor directing processing of digital data by the processor; a displaydevice coupled to the processor and memory for displaying informationderived from digital data processed by the processor; a plurality ofdatabases, and/or the like.

As will be appreciated by one of ordinary skill in the art, one or moresystem 101 components may be embodied as a customization of an existingsystem, an add-on product, upgraded software, a stand-alone system(e.g., kiosk), a distributed system, a method, a data processing system,a device for data processing, and/or a computer program product.Accordingly, individual system 101 components may take the form of anentirely software embodiment, an entirely hardware embodiment, or anembodiment combining aspects of both software and hardware. Furthermore,individual system 101 components may take the form of a computer programproduct on a computer-readable storage medium having computer-readableprogram code means embodied in the storage medium. Any suitablecomputer-readable storage medium may be utilized, including magneticstorage devices (e.g., hard disks), optical storage devices, (e.g.,DVD-ROM, CD-ROM, etc.), electronic storage devices (e.g., flash memory),and/or the like.

Client 110 may include an operating system (e.g., Windows, UNIX, Linux,Solaris, MacOS, iOS, Android, Windows Mobile OS, Windows CE, Palm OS,Symbian OS, Blackberry OS, J2ME, etc.) as well as various conventionalsupport software and drivers typically associated with mobile devicesand/or computers. Client 110 may be in any environment with access toany network, including both wireless and wired network connections. Invarious embodiments, access is through a network or the Internet througha commercially available web-browser software package. Client 110 andcrew planning system 115 components may be independently, separately orcollectively suitably coupled to the network via data links whichinclude, for example, a connection to an Internet Service Provider (ISP)over the local loop as is typically used in connection with standardwireless communications networks and/or methods, such as modemcommunication, cable modem, satellite networks, ISDN, digital subscriberline (DSL), and/or the like. In various embodiments, any portion ofclient 110 may be partially or fully connected to a network using awired (“hard wire”) connection. As those skilled in the art willappreciate, client 110 and/or any of the system components may includewired and/or wireless portions.

In various embodiments, components, modules, and/or engines of crewplanning system 115 may be implemented as micro-applications ormicro-apps. Micro-apps are typically deployed in the context of a mobileoperating system, including for example, a Palm mobile operating system,a Windows mobile operating system, an Android Operating System, AppleiOS, a Blackberry operating system, and the like. The micro-app may beconfigured to leverage the resources of the larger operating system andassociated hardware via a set of predetermined rules which govern theoperations of various operating systems and hardware resources. Forexample, where a micro-app desires to communicate with a device ornetwork other than the mobile device or mobile operating system, themicro-app may leverage the communication protocol of the operatingsystem and associated device hardware under the predetermined rules ofthe mobile operating system. Moreover, where the micro-app desires aninput from a user, the micro-app may be configured to request a responsefrom the operating system which monitors various hardware components andthen communicates a detected input from the hardware to the micro-app.

Internet server 125 may be configured to transmit data to client 110within markup language documents. “Data” may include encompassinginformation such as commands, messages, transaction requests, queries,files, data for storage, and/or the like in digital or any other form.Internet server 125 may operate as a single entity in a singlegeographic location or as separate computing components located togetheror in separate geographic locations. Further, Internet server 125 mayprovide a suitable web site or other Internet-based graphical userinterface, which is accessible by users (such as user 105). In variousembodiments, Microsoft Internet Information Server (IIS), MicrosoftTransaction Server (MTS), and Microsoft SQL Server, are used inconjunction with a Microsoft operating system, Microsoft NT web serversoftware, a Microsoft SQL Server database system, and a MicrosoftCommerce Server. In various embodiments, the well-known “LAMP” stack(Linux, Apache, MySQL, and PHP/Perl/Python) are used to enable crewplanning system 115. Additionally, components such as Access orMicrosoft SQL Server, Oracle, Sybase, InterBase, etc., may be used toprovide an Active Data Object (ADO) compliant database managementsystem.

Like Internet server 125, application server 142 may communicate withany number of other servers, databases and/or components through anymeans known in the art. Further, application server 142 may serve as aconduit between client 110 and the various systems and components ofcrew planning system 115. Internet server 125 may interface withapplication server 142 through any means known in the art including aLAN/WAN, for example. Application server 142 may further invoke softwaremodules, such as reserve forecasting module 145, automatically or inresponse to user 105 requests.

Any of the communications, inputs, storage, databases or displaysdiscussed herein may be facilitated through a web site having web pages.The term “web page” as it is used herein is not meant to limit the typeof documents and applications that may be used to interact with theuser. For example, a typical web site may include, in addition tostandard HTML documents, various forms, Java applets, JavaScript, activeserver pages (ASP), common gateway interface scripts (CGI), Flash filesor modules, FLEX, ActionScript, extensible markup language (XML),dynamic HTML, cascading style sheets (CSS), helper applications,plug-ins, and/or the like. A server may include a web service thatreceives a request from a web server, the request including a URL (e.g.,http://yahoo.com/) and/or an internet protocol (“IP”) address. The webserver retrieves the appropriate web pages and sends the data orapplications for the web pages to the IP address. Web services areapplications that are capable of interacting with other applicationsover a communications means, such as the Internet. Web services aretypically based on standards or protocols such as XML, SOAP, WSDL andUDDI. Web services methods are well known in the art, and are covered inmany standard texts. See, e.g., Alex Nghiem, IT Web Services: A Roadmapfor the Enterprise (2003).

Continuing to reference FIG. 1, illustrated are databases that areincluded in various embodiments. An exemplary list of various databasesused herein includes: an authentication database 135, a user database140, CDR 150 and/or other databases that aid in the functioning of thesystem. As practitioners will appreciate, while depicted as separateand/or independent entities for the purposes of illustration, databasesresiding within system 101 may represent multiple hardware, software,database, data structure and networking components. Furthermore,embodiments are not limited to the databases described herein, nor doembodiments necessarily utilize each of the disclosed databases.

Authentication database 135 may store information used in theauthentication process such as, for example, user identifiers,passwords, access privileges, user preferences, user statistics, and thelike. User database 140 maintains user information and credentials forcrew planning system 115 users (e.g., user 105).

In various embodiments, CDR 150 is a data repository that may beconfigured to store a wide variety of comprehensive data for crewplanning system 115. While depicted as a single logical entity in FIG.1, those of skill in the art will appreciate that CDR 150 may, invarious embodiments, consist of multiple physical and/or logical datasources. In various embodiments, CDR 150 stores operational data,schedules, resource data, asset data, inventory data, personnelinformation, routes and route plans, station (e.g., airports or otherterminals) data, operational alert data, weather information, passengerdata, reservation data, cost data, optimization results, booking classdata, forecasts, historical data, verification data, authenticationdata, demographic data, legal data, regulatory data, transaction data,security profiles, access rules, content analysis rules, audit records,predefined rules, process definitions, financial data, and the like. Forexample, a data source or component database of CDR 150 includes, but isnot limited to: historical line holder crew usage and assignments by (i)base, (ii) equipment, and (iii) seat (for example, position informationsuch as Captain or First Officer); historical reserve crew staffinglevels and usage by (i) base, (ii), equipment, and (iii) seat;historical crew and reserve crew sick calls and/or no-shows; pilotstatus change (PSC) levels (for example, for long term disability); newhire information; retirement information, short-call reserve levels;long-call reserve levels; training times for crew members; vacationinformation; and/or the like.

Any databases discussed herein may include relational, hierarchical,graphical, or object-oriented structure and/or any other databaseconfigurations. Common database products that may be used to implementthe databases include DB2 by IBM (Armonk, N.Y.), various databaseproducts available from Oracle Corporation (Redwood Shores, Calif.),Microsoft Access or Microsoft SQL Server by Microsoft Corporation(Redmond, Wash.), MySQL by MySQL AB (Uppsala, Sweden), or any othersuitable database product. Moreover, the databases may be organized inany suitable manner, for example, as data tables or lookup tables. Eachrecord may be a single file, a series of files, a linked series of datafields or any other data structure. Association of certain data may beaccomplished through any desired data association technique such asthose known or practiced in the art. For example, the association may beaccomplished either manually or automatically. Automatic associationtechniques may include, for example, a database search, a databasemerge, GREP, AGREP, SQL, using a key field in the tables to speedsearches, sequential searches through all the tables and files, sortingrecords in the file according to a known order to simplify lookup,and/or the like. The association step may be accomplished by a databasemerge function, for example, using a “key field” in pre-selecteddatabases or data sectors. Various database tuning steps arecontemplated to optimize database performance. For example, frequentlyused files such as indexes may be placed on separate file systems toreduce In/Out (“I/O”) bottlenecks.

One skilled in the art will also appreciate that, for security reasons,any databases, systems, devices, servers or other components of system101 may consist of any combination thereof at a single location or atmultiple locations, wherein each database or system includes any ofvarious suitable security features, such as firewalls, access codes,encryption, decryption, compression, decompression, and/or the like.

The systems and methods may be described herein in terms of functionalblock components, screen shots, optional selections and variousprocessing steps. It should be appreciated that such functional blocksmay be realized by any number of hardware and/or software componentsconfigured to perform the specified functions. For example, the systemmay employ various integrated circuit components, e.g., memory elements,processing elements, logic elements, look-up tables, and the like, whichmay carry out a variety of functions under the control of one or moremicroprocessors or other control devices. Similarly, the softwareelements of the system may be implemented with any programming orscripting language such as C, C++, C#, Java, JavaScript, Flash,ActionScript, FLEX, VBScript, Macromedia Cold Fusion, COBOL, MicrosoftActive Server Pages, assembly, PERL, SAS, PHP, awk, Python, VisualBasic, SQL Stored Procedures, PL/SQL, any UNIX shell script, and/orextensible markup language (XML) or the like, with the variousalgorithms being implemented with any combination of data structures,objects, processes, routines or other programming elements. Further, itshould be noted that the system may employ any number of conventionaltechniques for data transmission, signaling, data processing, networkcontrol, and the like. Still further, the system may be used to detector prevent security issues with a client-side scripting language, suchas JavaScript, VB Script or the like.

Software elements may be loaded onto a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions that execute on thecomputer or other programmable data processing means for implementingthe functions specified in the flowchart block or blocks. These computerprogram instructions may also be stored in a computer-readable memorythat can direct a computer or other programmable data processingapparatus to function in a particular manner, such that the instructionsstored in the computer-readable memory produce an article of manufactureincluding instruction means which implement the function specifiedherein or in flowchart block or blocks. The computer programinstructions may also be loaded onto a computer or other programmabledata processing apparatus to cause a series of operational steps to beperformed on the computer or other programmable apparatus to produce acomputer-implemented process such that the instructions which execute onthe computer or other programmable apparatus provide steps forimplementing the functions specified in the flowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions. Further, illustrations ofthe process flows and the descriptions thereof may make reference touser windows, web pages, web sites, web forms, prompts, etc.Practitioners will appreciate that the illustrated steps describedherein may comprise any number of configurations including the use ofwindows, web pages, web forms, popup windows, prompts and/or the like.It should be further appreciated that the multiple steps as illustratedand described may be combined into single web pages and/or windows buthave been expanded for the sake of simplicity. In other cases, stepsillustrated and described as single process steps may be separated intomultiple web pages and/or windows but have been combined for simplicity.

With continued reference to FIG. 1, in various embodiments, user 105logs onto an application (e.g., a module) and Internet server 125 mayinvoke an application server 142. Application server 142 invokes logicin the crew planning system 115 modules by passing parameters relatingto user's 105 requests for data. Crew planning system 115 managesrequests for data from crew planning system 115 modules and/orcommunicates with system 101 components. Transmissions between user 105and Internet server 125 may pass through a firewall 120 to help ensurethe integrity of crew planning system 115 components. Practitioners willappreciate that exemplary embodiments may incorporate any number ofsecurity schemes or none at all. In various embodiments, Internet server125 receives requests from client 110 and interacts with various othersystem 101 components to perform tasks related to requests from client110.

Internet server 125 may invoke an authentication server 130 to verifythe identity of user 105 and assign roles, access rights and/orpermissions to user 105. In order to control access to the applicationserver 142 or any other component of crew planning system 115, Internetserver 125 may invoke an authentication server 130 in response to user105 submissions of authentication credentials received at Internetserver 125. In response to a request to access system 101 being receivedfrom Internet server 125, Internet server 125 determines ifauthentication is required and transmits a prompt to client 110. User105 enters authentication data at client 110, which transmits theauthentication data to Internet server 125. Internet server 125 passesthe authentication data to authentication server 142 which queries theuser database 140 for corresponding credentials. In response to user 105being authenticated, user 105 may access various applications and theircorresponding data sources.

With reference now to FIGS. 1 through 2E, in various embodiments crewplanning system 115 and/or method 200 utilizes an optimization model forreserve crew planning which incorporates daily acceptable probabilisticrisk levels. In an embodiment, reserve forecasting module 145incorporates a distribution of forecasted daily open-time, for exampledue to unplanned sick, no-shows, and disrupted operations. Consequently,reserve forecasting module 145 allows users (for example, crew planners)to set minimum levels of daily risk, such as risk of a flightcancellation arising from insufficient reserve crew levels. By varyingthe minimum level of risk on a daily basis across the crew month,improved reserve demand forecasts may be obtained, and improved reservedemand staffing levels may be selected.

Typically, in the airline industry, unlike regular bidlines forline-holders, reserve crew work schedules do not consist of strings ofpairings. Rather, reserve crew work schedules represent consecutive dutydays where the crew member, for example a pilot or flight attendant, maybe required to fly. In addition, a reserve work schedule includesoff-duty periods that represent times where the crew member will notfly. The collection of these intermixed on-duty and off-duty sequencesare often referred to as “reserve patterns”. The 0/1 pattern belowrepresents a typical reserve pattern for a 30-day crew month.

${{Time}\mspace{14mu}( {{i.e.},{day}} )\mspace{14mu} t} = \begin{matrix}1 & 2 & 3 & 4 & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & . & 30 \\1 & 1 & 1 & 1 & 0 & 0 & 1 & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 1 & 1 & 1 & 1 & 1 & 0 & 0 & 0 & 1 & 1 & 1 & 1 & 0 & 0 & 0 & 0\end{matrix}$where a 1 represents an on-duty day and a 0 represents an off-duty dayof the crew month. In reserve forecasting module 145, a decisionvariable of a high-level problem reflects the decision to include (ornot include) a potential contractually feasible reserve crew schedule,such as the one illustrated above, in a potential crew staffingsolution. Stated another way, in reserve forecasting module 145 thisbinary decision variable may be defined mathematically as:

$\begin{matrix}{x_{j} = \{ {\begin{matrix}1 & {{if}\mspace{14mu}{pattern}\mspace{14mu} j\mspace{14mu}{is}\mspace{14mu}{included}\mspace{14mu}{in}\mspace{14mu}{the}\mspace{14mu}{solution}} \\0 & {otherwise}\end{matrix}\mspace{14mu}{\forall{j \in P}}} } & ( {{Equation}\mspace{14mu} 1} )\end{matrix}$

In an embodiment, reserve forecasting module 145 is configured todetermine a minimum number of reserves needed to cover the expectedreserve demand throughout the crew month, at a minimal acceptable riskset by a user. Stated differently, reserve forecasting module 145 may beconfigured to provide an answer to the question, “For each day, how manyreserve crew are needed in order to provide a desired level of certaintythat reserve crew demand will not exceed reserve crew supply?”

In an embodiment, in reserve forecasting module 145, a minimum number ofreserve crew needed to cover the expected demand may be representedmathematically as:

$\begin{matrix}( {{Equation}\mspace{14mu} 2} ) & \; \\{{\min\mspace{14mu}{Cost}} = {\sum\limits_{j \in P}x_{j}}} & (2)\end{matrix}$

where x_(j) represents the binary decision variable to include thereserve pattern j in the solution. P represents the set of all reservepatterns under consideration. Modifying Equation (2) to reflect thefinancial cost of the patterns selected to cover the expected demandyields:

$\begin{matrix}( {{Equation}\mspace{14mu} 2a} ) & \; \\{{\min\mspace{14mu}{Cost}} = {\sum\limits_{j \in P}{C_{j}x_{j}}}} & ( {2a} )\end{matrix}$

where C_(j) represents the financial cost of each reserve pattern j. Invarious embodiments, reserve forecasting module 145 incorporates otherobjective functions, and/or capabilities, for example approaches formaximizing utilization of reserve crews needed to cover the expectedopen time in a schedule. It will be appreciated that such capabilitiesmay utilize and/or incorporate additional constraints, input data,and/or the like.

In an embodiment, a primary constraint utilized by reserve forecastingmodule 145 insures that the number of crew reserves allocated on any dayt within the crew month meets or exceeds the number needed with aprobability of α_(t). In reserve forecasting module 145, this constraintmay be of the initial mathematical form:Γ(Σ_(j eP) A _(jt) x _(j) ≥d _(t))≥∝_(t) ∀t⊂T  (3)(Equation 3)

where A_(jt) represents a mapping coefficient configured to relate thereserve pattern to the day of the month t. In one embodiment, A_(jt)equals 1 if the reserve pattern j has an on-duty day on day t;similarly, A_(jt) equals 0 if the reserve pattern j has an off-duty dayon day t.

In various exemplary embodiments, reserve forecasting module 145incorporates probabilistic-based reserve planning model, which may berepresented mathematically as:

$\begin{matrix}{{\min\mspace{14mu}{Cost}} = {\sum\limits_{j \in P}x_{j}}} & (2)\end{matrix}$Subject to:

$\begin{matrix}{{P( {{\sum\limits_{j \in P}{A_{jt}x_{j}}} \geq d_{t}} )} \geq {\alpha_{t}\mspace{14mu}{\forall{t \in {T\mspace{14mu}{and}}}}}} & (3) \\{x_{j} = \{ {\begin{matrix}1 & {{if}\mspace{14mu}{pattern}\mspace{14mu} j\mspace{14mu}{is}\mspace{14mu}{included}\mspace{14mu}{in}\mspace{14mu}{the}\mspace{14mu}{solution}} \\0 & {otherwise}\end{matrix}\mspace{14mu}{\forall{j \in P}}} } & (1)\end{matrix}$

In various exemplary embodiments, in reserve forecasting module 145,Equation 3 represents a chance constraint where the physical constraintof allocating enough reserves to meet or exceed the forecasted expectedreserve demand, d_(t) is represented as a probability statement withdistribution f(d_(t)). ∝_(t) represents the minimum probability that thenumber of allocated reserve patterns on day t will exceed the forecastedreserve demand. Stated another way, ∝_(t) may be considered to representthe “reliability” of a particular reserve crew allocation. ∝_(t) mayhave a value between 0 (i.e., virtually no reliability) and 1 (i.e.,essentially perfect reliability).

By utilizing probabilistic techniques as disclosed herein, reserveforecasting module 145 is configured to evaluate and/or modify the levelof risk associated with a particular reserve staffing approach.Additionally, reserve forecasting module 145 may be configured toreceive a desired value of ∝_(t) as an input, and generate a proposedreserve staffing approach that meets or exceeds the desired ∝_(t) valuewhile simultaneously reducing and/or minimizing associated expenses. Inother words, ∝_(t) may be modeled as a variable within reserveforecasting module 145.

By way of comparison, prior crew planning and/or reserve crew planningapproaches do not incorporate probabilistic reliability approaches. As aresult, these prior approaches tend to either under-estimate orover-estimate the number of reserves needed, at least in part becausethey fail to incorporate the variation of the expected reserve demandinto their reserve planning process.

For example, past experience may indicate that an airline needs anaverage of 50 reserve pilots to service flights on a particular day,such as on the July 4^(th) holiday. However, past experience alsoindicates that the expected reserve demand associated with that day hasa large variance. It will be appreciated that a different level ofreserve staffing will be needed for a particular day when the standarddeviation is larger (for example, +/−20 reserves) as compared to whenthe standard deviation is smaller (for example, +/−5 reserves). When thevariance is small, providing reserve staffing approximately equal to anexpected reserve demand may work well. However, as the variance of theexpected reserve demand increases, the likelihood of not covering theschedule also increases, leaving the carrier at risk of having a crewshortage that results in costly cancellations. In accordance withprinciples of the present disclosure, in various embodiments crewplanning system 115 is configured to account for such risks, allowing acrew planner to control risk exposure, for example by varying theacceptable risks on a daily basis across the crew month.

With momentary reference to FIGS. 2A and 2B, in various embodimentsreserve forecasting module 145 is configured to evaluate and/or modelreserve demand 271. Prior approaches often allocated reserves based uponpeak day demand (illustrated as dashed line 275 in FIG. 2A); incontrast, in accordance with principles of the present disclosure,reserve forecasting module 145 is configured to consider theprobabilistic components of reserve demand 271. Stated another way,reserve demand 271 may be considered to be a set of daily reservedemands, with reserve demand for each day 272 having a correspondingprobability distribution 273. The probability distribution associatedwith reserve demand for a particular day 272 (for example, probabilitydistribution 273A) may vary from the probability distribution associatedwith a different day 272 (for example, probability distribution 273B or273C).

Continuing to reference FIGS. 1 through 2E, in various embodimentsreserve forecasting module 145 may be configured to model the risk ofnot covering the expected reserve demand. In an embodiment, reserveforecasting module 145 may model and/or determine the risk using thecomplement of Equation 3, which may be expressed as:

$\begin{matrix}( {{Equation}\mspace{14mu} 3a} ) & \; \\{{P( {{\sum\limits_{j \in P}{A_{jt}x_{j}}} \geq d_{t}} )} \leq {1 - {\alpha_{t}\mspace{14mu}{\forall{t \in T}}}}} & ( {3a} )\end{matrix}$

where 1−∝_(t) represents the risk of not having enough reserves to covera particular schedule on day t. In Equations 3 and 3a, the reservedemand, d_(t), represents a random variable.

It will be appreciated by those skilled in the art that the constraintsrepresented by Equation 3 and Equation 3a may be problematic for integerprogramming techniques. Both of these constraints represent nonlinearfunctions. In accordance with various exemplary embodiments, in reserveforecasting module 145 these constraints may be modeled via approachesother than integer programming. Reserve forecasting module 145 may beconfigured to consider d_(t) a random variable with a mean (P_(dt)),variance (σ_(dt)), and a known distribution distribution f(d_(t)); inthis instance reserve forecasting module 145 may consider Equation 3a torepresent the cumulative distribution function, F(⋅), of the expecteddaily reserve demand. Accordingly, in reserve forecasting module 145,this constraint may be modeled and/or expressed in terms of a cumulativedistribution function (CDF) as follows:

$\begin{matrix}( {{Equation}\mspace{14mu} 4} ) & \; \\{{F( {\sum\limits_{j \in P}{A_{jt}x_{j}}} )} \geq {1 - {\alpha_{t}\mspace{14mu}{\forall{t \in T}}}}} & (4)\end{matrix}$

In reserve forecasting module 145, inverting the cumulative distributionfunction yields the following deterministic equivalent constraint:

$\begin{matrix}( {{Equation}\mspace{14mu} 5} ) & \; \\{{\sum\limits_{j \in P}\;{A_{jt}x_{j}}} \geq {{F^{- 1}( {1 - \alpha_{t}} )}\mspace{14mu}{\forall{t \in T}}}} & (5)\end{matrix}$

In various embodiments, in reserve forecasting module 145 the resultF⁻¹(1−α_(t)) can be evaluated for a given level of acceptable risk,(1−α_(t)), in order to obtain a lower bound on the number of reservesneeded to cover the schedule on day t. Stated another way, reserveforecasting module 145 may be utilized to determine the likelihood of aparticular number of reserves being sufficient to cover reserve demandfor that day.

This lower bound may be utilized as an input to an optimization model,which may be internal to reserve forecasting module 145, or which may beexternal to reserve forecasting module 145 (for example, as part ofexternal systems and databases 160).

It will be appreciated that, in reserve forecasting module 145, apractical extension to evaluating the probabilistic term a priori allowsan acceptable level of risk to be evaluated as part of an optimizationsolution. In reserve forecasting module 145, because the deterministicequivalent constraint is derived from the cumulative distributionfunction, it can be shown to represent a concave function for ∝_(r)greater than 0.5. Accordingly, reserve forecasting module 145 maygenerally be utilized to obtain and/or consider solutions that have areliability of at least 50% on any day of the crew month. Stateddifferently, solutions having a reliability of less than 50% wouldpromote scenarios that promote crew shortfalls, and such solutions maydesirably be disregarded.

With reference now to FIGS. 3A and 3B, in various exemplary embodimentscrew planning system 115 models expected reserve demand, for example byutilizing a probability distribution model. By using a probabilitydistribution rather than simple average demand, crew planning system 115explicitly incorporates the stochastic effect of reserve demandvariability. FIG. 3A illustrates an exemplary probability distributionof reserve demand resulting from operation of crew planning system 115.FIG. 3B illustrates an exemplary cumulative distribution function usablein crew planning system 115 to evaluate risk as a constraint. It will beappreciated that using a cumulative distribution function allows crewplanning system 115 to include risk levels as part of an overalloptimization solution, rather than simply utilizing risk as an inputprovided by a user 105 (for example, a crew planner).

In various exemplary embodiments, reserve forecasting module 145 may beutilized to maximize the reliability (or minimize the risk) associatedwith a reserve planning solution. Because the deterministic constraintremains nonlinear, it can be modeled using a suitable mathematicalapproach, such as piecewise linear approximation or a decompositiontechnique such as Benders Decomposition. In one embodiment, reserveforecasting module 145 is configured to consider the basicprobabilistic-based reserve model formulation as:

$\begin{matrix}( {{Equation}\mspace{14mu} 2b} ) & \; \\{{\min\mspace{14mu}{Cost}} = {{\sum\limits_{j \in P}\;{C_{j}x_{j}}} + {\sum\limits_{t \in T}\;{C_{t}^{\prime}( {{1 -} \propto_{t}} )}}}} & \;\end{matrix}$where C_(j) represents the financial cost of selecting reserve pattern jas part of a selected solution.

Subject to:

$\begin{matrix}( {{Equation}\mspace{14mu} 5A} ) & \; \\{{{\sum\limits_{j \in P}\;{A_{jt}x_{j}}} - {F^{- 1}( {1 - \alpha_{t}} )}} \geq {0\mspace{14mu}{\forall{t \in T}}}} & ( {5a} ) \\( {{Equation}\mspace{14mu} 6} ) & \; \\{\propto_{t} \geq \propto_{\min}\mspace{14mu}{\forall{t \in {T\mspace{14mu}{and}}}}} & (6) \\( {{Equation}\mspace{14mu} 1} ) & \; \\{x_{j} = \{ {\begin{matrix}1 & {{if}\mspace{14mu}{pattern}\mspace{14mu} j\mspace{14mu}{is}\mspace{14mu}{included}\mspace{14mu}{in}\mspace{14mu}{the}\mspace{14mu}{solution}} \\0 & {otherwise}\end{matrix}\mspace{14mu}{\forall{j \in P}}} } & (1)\end{matrix}$

In this embodiment, in reserve forecasting module 145 Equation 2brepresents a modification of Equation 2 to incorporate a cost, C′_(t),of not having enough reserve crews to cover the schedule when lineholders cannot meet their obligated bidlines. In various embodiments, asuitable method may be applied for estimating or calibrating a value forthe cost parameter C′_(t). One exemplary method utilizes an ad-hocheuristic to estimate a general penalty value for C′_(c); such anapproach uses the same unit penalty for all incremental values ofrisk(1−α_(t)). This exemplary method has the advantage of simplicity,but it represents a blunt approach which may underestimate oroverestimate the true impact of a change in the risk compared to thecost of an added reserve crew to cover the schedule.

Another exemplary method utilizes a financial estimate of the true costof cancelling a flight on day t (or the cost of canceling one or moreflights on day t). This exemplary method is more complicated, andprovides an estimate of the realistic cost of the cancellation and itsimpact on the flight schedule for the remainder of the day. It will beappreciated that a financial estimate method may vary significantly fromcarrier to carrier; however, a financial estimate method assigns a costof cancelling a flight to provide an incentive to reserve forecastingmodule 145 to avoid cancellations. Moreover, a financial estimate methodmay utilize extended cost estimates to reflect nonlinear aspects ofcancellation costs (for example, allowing the unit costs to increase) asthe risk on any given day in the planning horizon increases. In thismanner, reserve forecasting module 145 may account for the increase incost due to the possibility that as the risk increases, the number oflikely cancellations will also increase.

In various exemplary embodiments, in reserve forecasting module 145,Equation 5a may be utilized as an alternative form of Equation 5, whereF⁻¹(1−α_(t)) represents a nonlinear variable, rather than a constantmodeled using piecewise linearization or Benders Decomposition.Additionally, in reserve forecasting module 145 Equation 6 may be usedto represent a common lower bound for the reliability or likelihood ofcovering the schedule on day t. The common lower bound may be selectedas suitable, for example by a crew planner.

In accordance with principles of the present disclosure, output ofreserve forecasting module 145 (for example, solutions for the modelsdescribed by Equations 1-3 or Equations 1, 2b, 5a and 6) enables crewplanning groups to determine reserve staffing needs. Using reserveforecasting module 145, crew planners obtain access to information thatmore accurately represents reality, at least in part by incorporatingthe probabilistic nature of line-holder disruptions, sick calls, and noshows that define reserve demand on a daily basis. In addition, reserveforecasting module 145 allows crew planners or other decision makers toevaluate the tradeoffs that exist between reserve crews levels and thelikelihood of flight cancellations due to crew shortfalls.

For example, via use of reserve forecasting module 145, crew planninganalysts can evaluate the trade-off between reserve crew and thelikelihood of cancelling flights by stipulating a minimum acceptablerisk (1−α_(t)) as an input to an optimization model. Solving theoptimization model for many values of the minimum acceptable risk yieldsa trade-off between the risk of cancellation and the total costassociated with covering the schedule with reserve crew. In accordancewith principles of the present disclosure, FIG. 2F provides anillustration of the trade-off or non-inferior set of solutions producedusing this approach. Moreover, any suitable method for evaluating themulti-objective trade-offs can also be used to produce thisrelationship. In sum, via use of reserve forecasting module 145, moreefficient reserve plans and schedules may be obtained. The overallnumber of reserves needed may be reduced by better matching reserveallocations to forecasted demand.

With continued reference to FIGS. 1 through 2F, in various embodimentscrew planning system 115 is configured to provide accurate reservedemand forecasting. It will be appreciated that, absent reasonableforecasts of the reserve mean, standard deviation (function of variance)and a form of the distribution, exemplary optimization models maystruggle to accurately allocate reserves and/or control the risk of notcovering the schedule. Accordingly, crew planning system 115 may beconfigured to implement a customized forecasting module, for examplereserve forecasting module 145, in order to calibrate and forecastreserve demand based on historical data, while accounting forvariability arising from seasonal factors, special events, and/or thelike.

In an embodiment, reserve forecasting module 145 utilizes regression toforecast the likely open duty periods (ODP) level for each day in theforecasting horizon based on historical operational data for ODP levels.The forecasting horizon may be any suitable time period, for example oneweek, four weeks, one month, two months, and/or the like. Reserveforecasting module 145 is configured to consider a daily historicalprofile of block hours and ODP. Reserve forecasting module 145 is alsoconfigured to consider that the historical daily profile resembles thefuture planning horizon on average. A planning horizon is typicallydefined as a 30 or 31 day planning period.

Reserve forecasting module 145 uses regression to create forecastoutput. In an embodiment, forecast output comprises the mean andstandard deviation of ODP. In reserve forecasting module 145, in oneregression model, a linear function of ODP is fitted using seven (7)structural variables. The structural variables include block hours as acontinuous variable, and six time-based indicator variables that accountfor impacts such as seasonality, and weekend or weekday events. Theindicator variables have values of either 0 (when the conditions are notfulfilled) or 1 (when the conditions are fulfilled). In one embodiment,in reserve forecasting module 145 an indicator variable is included inthe regression formulation if the data meets the seasonality condition.Otherwise, the indicator variable will equal 0 and not be included inthe regression model.

In various embodiments, reserve forecasting module 145 utilizes thefollowing indicator variables:

Peak days—defined as days historically having excessive demand (forexample, the week of Thanksgiving, the week of Christmas and New Year,etc.).

Transition day—defined as the first four days of the planning period.

Weekend—defined as Saturday and Sunday.

Shoulder weekday—defined as Tuesday and Wednesday.

Summer months—defined as May, June, and July.

Shoulder-Fall months—defined as August and September.

It will be appreciated that fewer variables and/or additional variablesmay be utilized in reserve forecasting module 145. In reserveforecasting module 145, the indicator variables may be configured with adominant relationship or hierarchy within the regression process. In oneembodiment, peak days are dominant over other indicator variables. If aday is designated as peak day, it does not belong to any of the weekend,shoulder, summer and shoulder-fall seasons. In this embodiment, atransition day is only dominant over weekend and weekday; in otherwords, if a day is designated as a transition day, it is not consideredas a weekday or weekend. Reserve forecasting module 145 may beconfigured with different transition days for different seasons.

Reserve forecasting module 145 may be configured to restrict historicaldata, for example based on a boundary filter. In this manner, reserveforecasting module 145 can account for and/or appropriately considercircumstances when the nature of the historical data has changed, forexample when equipment historical nature or mission has changedsubstantially during the period covered by the historical data. Forexample, reserve forecasting module 145 may be configured to exclude atleast a portion of historical data associated with a plane that flew for14000 annual block hours on average 3 years ago, but is currentlyrunning only 10000 annual block hours, for example due to anticipatedretirement of the plane.

With reference specifically to FIG. 2C, in an embodiment a method 200for reserve planning comprises forecasting a reserve demand including amean and standard deviation (step 210), optimizing a risk-based solutionto meet the reserve demand (step 220), and evaluating the solution (step230). Feedback regarding the efficacy of the selected solution may beutilized as an input to refine future demand forecasts (step 240).

With additional reference to FIG. 2D, in one embodiment, in method step210 of method 200, reserve forecasting module 145 prepares a subset ofhistorical ODP and block time data based on specified filters (forexample, selecting a time period of May 2009 through January 2011) (step211). Reserve forecasting module 145 assigns indicator variables foreach day, based at least in part on its property and dominantrelationship (step 212). Reserve forecasting module 145 fits a linearregression model of ODP as a function of block hour and the specifiedindicator variables (step 213). Regression results include thecoefficients for the block hour and each indicator variable as well asthe intercept. Using the calibrated coefficients, reserve forecastingmodule 145 utilizes the regression equation to estimate the meanforecast of the open duty periods (ODP) (step 214).

In various embodiments, reserve forecasting module 145 determines astandard deviation based at least in part on a dominant relationship ofthe indicator variables (step 215). Reserve forecasting module 145calculates standard deviations based on ODP historical data within thesame range as previously used for the regression. Reserve forecastingmodule 145 may be configured to utilize the following list of groupswhen determining standard deviations:

Peak days (designated by peak-day=1), considered as 20% of the historicaverage of peak days.

Weekday—base month (weekend=0, shoulder=0, summer=0, shoulder-fall=0).

Weekend—base month (weekend=1, shoulder=0, summer=0, shoulder-fall=0).

Shoulder weekday—base month (weekend=1, shoulder=0, summer=0,shoulder-fall=0).

Transition—base month (transition=1, summer=0, shoulder-fall=0).

Weekday—summer month (weekend=0, shoulder=0, summer=1, shoulder-fall=0).

Weekend—summer month (weekend=1, shoulder=0, summer=1, shoulder-fall=0).

Shoulder weekday—summer month (weekend=1, shoulder=0, summer=1,shoulder-fall=0).

Transition—summer month (transition=1, summer=1, shoulder-fall=0).

Weekday—shoulder-fall month (weekend=0, shoulder=0, summer=0, shoulderfall=1).

Weekend—shoulder-fall month (weekend=1, shoulder=0, summer=0, shoulderfall=1).

Shoulder weekday—shoulder-fall month (weekend=1, shoulder=0, summer=0,shoulder fall=1).

Transition—shoulder fall month (transition=1, summer=0, shoulderfall=1).

In reserve forecasting module 145, the base month includes thepeak-season and other months not designated as summer/shoulder-fall. Apeak day has an indicator on peak-day and peak-season. Standarddeviation is calculated as the square root of (Sum of square (x−meanx)/n−1).

In various embodiments, reserve forecasting module 145 is configured todetect and/or account for outliers in the historical data. In oneembodiment, in reserve forecasting module 145, an observation is definedas an outlier if it skews the average calculation by more than aselected percentage, for example 2%, 3%, 4%, 5%, and/or 10%. Reserveforecasting module 145 utilizes an iterative scheme to remove outlierobservations.

The foregoing standard deviation calculations are utilized in certainembodiments of reserve forecasting module 145 due to the nature ofregression model, to separate the data and forecasts based on thelift-effect from the various indicator variables. In other exemplaryembodiments, reserve forecasting module 145 utilizes a modifiedcalculation of standard deviation configured to account for the presenceof additional continuous variables. Regardless of the standard deviationcalculation approach employed in reserve forecasting module 145, reserveforecasting module 145 may be configured to validate the standarddeviation calculations by comparing them with the calculated mean toobtain a coefficient of variation (CV) (step 216). A CV greater than atarget value (for example, 0.4, 0.6, and/or the like) for a large numberof observations (for example, more than 30 observations) may result in anotification displayed for a user 105 (for example, an indication thatthe data set has a high variance that may result in increases in risk).It will be appreciated that, responsive to such notification, a crewplanner may recognize that a reserve staffing level may need to bemodified; moreover, a crew planner may recognize that the increasedvariance in the historical data is due to a special event that may notoccur in the future and adjust the allowable risk for those days in themonth accordingly.

In various embodiments, reserve forecasting module 145 is configured toutilize certain assumptions when determining the mean and variance ofthe ODP forecast, the corresponding impact on optimization module 147,and ultimately, the calculated final number of reserves needed to covera particular schedule at a desired level of risk. In one embodiment,reserve forecasting module 145 utilizes the following assumptions:

-   -   The forecast is assumed to represent the mean value of the ODP        and an outcome of the regression process.    -   The standard deviation represents the variability of the data        around the mean forecast and is based on historical data.    -   The standard deviation is calculated using the process described        herein. In some embodiments, the standard deviation is based on        a preset coefficient of variation; in other embodiments, the        standard deviation is based on historical data minus outliers.    -   Outlier detection is based on data sets greater than a selected        number of observations (for example, 4, observations, 5        observations, or 6 observations; in general any selected number        of observations that is acceptable to a user 105), and        observations that influence the mean by more than a selected        percentage (for example, 2%, 3%, 4%, 5%, 10%, and/or the like;        in general, any selected percentage desired by a user 105) may        be discarded.    -   The distribution of the forecast is assumed to be normal.    -   The regression model and standard deviation assume sufficient        historical data exists to accurately calibrate the model.    -   Any day within the forecast horizon and historical data must        comply with one of the 12 group combinations used to estimate        the standard deviation.

It will be appreciated that, in various exemplary embodiments, incertain instances a user 105 may “prime” crew planning system 115 withgeneric seasonal levels derived from a similar fleet type in which datadoes exist (in lieu of actual historical data, for example whenassessing a new fleet type, a new set of crew, and/or the like).

Returning again to FIG. 1, in various embodiments crew planning system115 utilizes optimization module 147 to solve a risk-based optimizationmodel, using the forecasted demand and variance output by reserveforecasting module 145. Optimization module 147 uses a sub-problem togenerate potential feasible on-duty/off-duty patterns used to determinethe number of reserve crew needed to meet the expected reserve demand.Optimization module 147 generates reserve bid-lines, for example basedon contractual rules governing reserve bid-line construction.

In accordance with principles of the present disclosure, in oneembodiment optimization module 147 utilizes two integrated models todetermine the optimal number of reserve crews needed to cover the ODPlevels. The first model generates the possible bid-lines that can beused to cover the ODP on a schedule. Optimization module 147 uses asuitable algorithm (for example, an algorithm similar to one used togenerate crew pairings for line holder optimization) to generate a poolof potential reserve patterns from which a risk-based solution may beselected (i.e., a number of reserves needed to cover the schedule for aparticular day). As used herein, in optimization module 147 the processof generating pairings or potential reserve patterns may be referred toas the “sub-problem”. Optimization module 147 selects the bid-linesneeded to cover the ODPs, such that the number of reserves needed isminimized while meeting the risk limits specified by a user 105, forexample a crew planner. In optimization module 147, the risk-basedreserve optimization model is configured to solve what is often referredto as the “master” problem.

Optimization module 147 is configured to generate reserve patterns. Thebid-line generator determines the possible bid-lines that can be used tocover ODPs, for example based at least in part on contractual crewrules, federal regulations, and/or the like. To be considered aspotentially suitable, the lines generated by the sub-problem should tobe feasible and reasonably efficient lines.

In various embodiments, optimization module 147 is configured toincorporate and/or utilize the following contractual rules:

-   -   Reserve staff can work for at most 18 working days within a        planning period;    -   Reserve staff must have at least 4 consecutive days-off (INF)        days;    -   Reserve staff must have at least 2 consecutive days-off when not        working; and    -   Reserve staff can at most be assigned to 6 consecutive working        days.        It will be appreciated that, depending on regulatory        requirements, contractual obligations, and/or the like,        additional, fewer, and/or differing contractual rules may be        applicable and thus considered by optimization module 147; the        foregoing are presented by way of illustration and not of        limitation.

In various embodiments, optimization module 147 is configured toimplement a minimum working day rule. For example, a minimum working dayrule may specify a minimum number of workdays within the reserve patternor assigned line. The minimum working day rule may be based at least inpart on equipment (for example, Airbus 320 vs. Boeing 737), position(Captain vs. First Officer), and/or the like.

In various embodiments, crew planning system 115 utilizes reserveforecasting module 145 and optimization module 147 to formulate anddetermine the number of reserve crews needed to cover the schedule at aparticular level of risk. Additionally, crew planning system 115 may beconfigured to implement and/or facilitate a feedback loop. In thismanner, crew planning system 115 allows a user 105, for example a crewplanner, to refine risk levels and adjust a solution as desired, forexample in order to better match transitions between boarding months,special events, holidays, and so forth.

Via use of crew planning system 115, modification of risk levels for aparticular day in a forecast period (for example, accepting a higherlevel of risk for that day) may be utilized to modify risk levels for adifferent day in a forecast period (for example, creating a lower levelof risk for that day), all without incurring additional reserve expenses(i.e., with a fixed number of reserve resources). For example, for acertain high-traffic date, a high level of certainty (i.e., very lowrisk) regarding reserve staffing levels may be desired. Via use of crewplanning system 115, a user 105, such as a crew planner, may increaserisk levels associated with other dates in the forecast period,resulting in a lowering of reserve staff allocated to thoselower-priority days. Consequently, based on contractual obligations,regulatory requirements, and so forth, additional reserve staff may nowbe available for the high-traffic date. Thus, additional reserve staffmay be allocated to the high-traffic date in order to decrease the risklevel associated with that date.

Crew planning system 115 enables improved risk allocation decisions andimplementation. Viewed from a baseline cost and risk perspective, crewplanning system 115 allows modified and/or reduced risk levels comparedto the baseline to be obtained for the baseline cost; conversely, crewplanning system 115 also allows baseline risk levels to be obtained at abelow-baseline cost.

In crew planning system 115, variables and parameters, such asacceptable risk for a particular day, may be revised, adjusted, and/ormodified, for example on a daily basis. Crew planning system 115 canthus quickly respond to external factors influencing reserve demand (forexample, widespread illness, civil unrest, labor disruptions, weather,equipment failures, and the like) in order to (i) reduce and/or minimizethe chances for flight cancellations arising from insufficient reservestaffing levels, and/or (ii) reduce expenses associated withoverstaffing of reserve demand.

It will be appreciated that as an organization's tolerance for riskdecreases, the value of principles of the present disclosure (forexample, use of crew planning system 115) to that organizationincreases.

With reference now to FIG. 4, exemplary results of operation of anembodiment of crew planning system 115 are illustrated. In FIG. 4,results of operation of an embodiment of crew planning system 115 arepresented for an exemplary December month of flight schedule data for agroup of pilots (for example, AirBus captains) based out of a particularcity (for example, Philadelphia). In the exemplary embodimentillustrated in FIG. 4, a global allowable risk of 10% for each day wasutilized.

In FIG. 4, a traditional reserve forecasting approach utilizing peakdemand generated the proposed reserve demand staffing level 451. Incontrast, crew planning system 115 generated the proposed reserve demandstaffing level 462. In addition, historical data for the exemplaryDecember month is plotted in FIG. 4 as actual reserve demand 473. FIG. 4illustrates how crew planning system 115 does a better job at allocatingreserves as compared to prior approaches, particularly with respect tothe peak reserve demand levels seen from approximately December 20onwards.

Via use of crew planning system 115, opportunities to reduce the totalnumber of reserves needed to cover a schedule may be identified. Table 1illustrates potential reserve staffing savings arising from use of crewplanning system 115, assuming only a minimum savings for each month ofthe year. It will be appreciated that in Tables 1 and 2, an exampleindustry standard wage plus fringe for pilots and flight attendants isutilized; actual values may vary significantly based on the carrier,collective bargaining agreements, and so forth.

TABLE 1 Reduction in Annual Unit Category and Reserves Cost TotalSavings Equipment (Minimum) ($) ($) Pilots E9 0 $119,153     $0 AB 0$119,153     $0 7I 6 $119,153 $714,918 33 0 $119,153     $0 30 0$119,153     $0 Pilot Savings 6 $714,918 First Officers E9 0 $119,153    $0 AB 16 $119,153 $1,906,448 7I 17 $119,153 $2,025,601 33 0 $119,153    $0 30 0 $119,153     $0 F.O. Savings 33 $3,932,049 Flight AttendantsMix 64  $37,452 $2,399,488 Total Savings $7,046,455

In Table 2, potential annual savings associated with use of crewplanning system 115 are illustrated, assuming average reserve reductionsthroughout the year.

TABLE 2 Reduction in Annual Unit Category and Reserves Cost TotalSavings Equipment (Average) ($) ($) Pilots E9 1 $119,153   $119,153 AB 7$119,153   $834,071 7I 10 $119,153 $1,191,530 33 7 $119,153   $834,07130 16 $119,153 $1,906,448 Pilot Savings 41 $4,885,273 First Officers E93 $119,153   $357,459 AB 35 $119,153 $4,170,355 7I 28 $119,153$3,336,284 33 20 $119,153 $1,191,530 30 5 $119,153   $595,765 F.O.Savings 81 $9,651,393 Flight Attendants Mix 113 $37,452 $4,232,076 TotalSavings $18,768,742

It will be appreciated that in actuality, results associated withutilization of crew planning system 115 are likely to fall somewherebetween the values shown in Table 1 and the values shown in Table 2.Moreover, savings associated with use of crew planning system 115 may bevariable depending on the level of acceptable risk selected by a user105, for example a crew planner. For example, if a user 105 utilizes anacceptable risk of 0.001 in crew planning system 115 (i.e., to obtain asolution having a 99.99% probability of covering the reserve demand),the number of required reserves will grow excessively. Accordingly, inpractical applications of crew planning system 115, a user 105 mayutilize the risk level to “trade-off” risk-exposure during a low demandperiod with risk exposure during a high demand period.

For example, many airlines see a higher number of sick calls duringholiday seasons like Christmas, Thanksgiving, and New Year. In contrast,the number of sick calls is often very low in early December. Thus, inthese instances, a user 105 may utilize crew planning system 115 toselect a higher level of risk during the early part of December (forexample, 1−α_(t)=0.25), and a lower level of risk during the holidays(for example, 1−α_(t)=0.05). By utilizing crew planning system 115 andselecting risk levels that vary during the month, for example based onprevious experience and historical distributions, a user 105 may hedgeagainst crew shortages during high demand periods. Stated another way,in this manner a user 105 may utilize crew planning system 115 togenerate and/or select reserve patterns that bias on-duty time to daysof the month when expected reserve demand is high (and thus, whenreserve crews are difficult to obtain on short notice). Similarly, inthis manner a user 105 may utilize crew planning system 115 to generateand/or select reserve patterns that favor off-duty days where reservedemand is low (and thus, when reserve crews are relatively easy toobtain). In sum, crew planning system 115 allows a user 105 to closelytailor reserve schedules to capture high demand periods and bettercontrol the risk of having crew shortfalls during critical times of theyear.

Principles and features of the present disclosure may suitably becombined with principles of revenue management, for example as disclosedin U.S. patent application Ser. No. 13/348,417 entitled “Overbooking,Forecasting, and Optimization Methods and Systems” filed on Jan. 11,2012, now U.S. Patent Application 2013-0132128 Published on May 23,2013, which is incorporated herein by reference in its entirety.

Principles of the present disclosure may suitably be combined withprinciples of forecasting, demand modeling, and/or the like, for exampleas disclosed in U.S. patent application Ser. No. 13/791,672 entitled“Demand Forecasting Systems and Methods Utilizing Unobscuring andUnconstraining” filed on Mar. 8, 2013, now U.S. Patent ApplicationPublication 2014-0257925 published on Sep. 11, 2014, U.S. patentapplication Ser. No. 13/791,691 entitled “Demand Forecasting Systems andMethods Utilizing Fare Adjustment” filed on Mar. 8, 2013, now U.S.Patent Application Publication 2014-0257881 published on Sep. 11, 2014,and U.S. patent application Ser. No. 13/791,711 entitled “DemandForecasting Systems and Methods Utilizing Prime Class Remapping” filedon Mar. 8, 2013, now U.S. Patent Application publication 2014-0257882published on Sep. 11, 2014, each of which are incorporated herein byreference in their entirety.

While the present disclosure may be described in terms of an airport, anaircraft, a pilot, and so forth, one skilled in the art can appreciatethat similar features and principles may be applied to othertransportation systems and vehicles such as, for example, buses, trains,ships, trucks, automobiles and/or the like.

While the exemplary embodiments described herein are described insufficient detail to enable those skilled in the art to practiceprinciples of the present disclosure, it should be understood that otherembodiments may be realized and that logical and/or functional changesmay be made without departing from the spirit and scope of the presentdisclosure. Thus, the detailed description herein is presented forpurposes of illustration and not of limitation.

While the description references specific technologies, systemarchitectures and data management techniques, practitioners willappreciate that this description is of various embodiments, and thatother devices and/or methods may be implemented without departing fromthe scope of principles of the present disclosure. Similarly, while thedescription references a user interfacing with the system via a computeruser interface, practitioners will appreciate that other interfaces mayinclude mobile devices, kiosks and handheld devices such as mobilephones, smart phones, tablet computing devices, etc.

While the steps outlined herein represent exemplary embodiments ofprinciples of the present disclosure, practitioners will appreciate thatthere are any number of computing algorithms and user interfaces thatmay be applied to create similar results. The steps are presented forthe sake of explanation only and are not intended to limit the scope ofthe present disclosure in any way. Benefits, other advantages, andsolutions to problems have been described herein with regard to specificembodiments. However, the benefits, advantages, solutions to problems,and any element(s) that may cause any benefit, advantage, or solution tooccur or become more pronounced are not to be construed as critical,required, or essential features or elements of any or all of the claims.

Systems, methods and computer program products are provided. In thedetailed description herein, references to “various embodiments”, “oneembodiment”, “an embodiment”, “an example embodiment”, etc., indicatethat the embodiment described may include a particular feature,structure, or characteristic, but every embodiment may not necessarilyinclude the particular feature, structure, or characteristic. Moreover,such phrases are not necessarily referring to the same embodiment.Further, when a particular feature, structure, or characteristic isdescribed in connection with an embodiment, it is submitted that it iswithin the knowledge of one skilled in the art to utilize such feature,structure, or characteristic in connection with other embodimentswhether or not explicitly described. After reading the description, itwill be apparent to one skilled in the relevant art(s) how to implementprinciples of the disclosure in alternative embodiments.

It should be understood that the detailed description and specificexamples, indicating exemplary embodiments, are given for purposes ofillustration only and not as limitations. Many changes and modificationsmay be made without departing from the spirit thereof, and principles ofthe present disclosure include all such modifications. Correspondingstructures, materials, acts, and equivalents of all elements areintended to include any structure, material, or acts for performing thefunctions in combination with other elements. Reference to an element inthe singular is not intended to mean “one and only one” unlessexplicitly so stated, but rather “one or more.” Moreover, when a phrasesimilar to “at least one of A, B, or C” or “at least one of A, B, and C”is used in the claims or the specification, the phrase is intended tomean any of the following: (1) at least one of A; (2) at least one of B;(3) at least one of C; (4) at least one of A and at least one of B; (5)at least one of B and at least one of C; (6) at least one of A and atleast one of C; or (7) at least one of A, at least one of B, and atleast one of C.

What is claimed is:
 1. A method comprising: forecasting, by a computer,a daily reserve airline staff demand level for each day in a first timeperiod, wherein the forecasting utilizes a probabilistic reservestaffing model based on a minimum probability that a selected reservepattern will exceed the predicted daily reserve airline staff demandlevel, a financial cost of selecting a reserve pattern as part of aselected solution, a financial cost of having insufficient reserve crewsto cover a scheduled set of airline flights in the first time period anda mapping coefficient configured to relate the reserve pattern to acorresponding day in the first time period; optimizing, by the computer,the probabilistic reserve staffing model to generate a reserve airlinestaffing level for each day in the first time period; storing, by thecomputer, the reserve airline staffing level in a database; tuning, bythe computer, the database to optimize performance of the database;designating, by the computer, the reserve airline staffing level as akey field in a plurality of related data tables to speed searching fordata; linking, by the computer, the plurality of related data tablesbased on the type of the reserve airline staffing level in the keyfield; receiving, by the computer, updated risk information; andmodifying, by the computer and responsive to the updated riskinformation, the reserve airline staffing level for a first day in thefirst time period in order to modify a risk variable associated with thereserve airline staffing level for a second day in the first timeperiod.
 2. The method of claim 1, further comprising: evaluating, by thecomputer, a result of the probabilistic reserve staffing model for eachday in the first time period to determine reserve airline staffingresults information; and utilizing, by the computer, the reserve airlinestaffing results information to forecast a daily reserve airline staffdemand level for each day in a second time period.
 3. The method ofclaim 1, wherein the forecasting further comprises: accessing, by thecomputer, historical reserve airline staff demand information, whereinthe historical reserve airline staff demand information is associatedwith at least one indicator value; determining, by the computer, aregression model for the historical reserve airline staff demandinformation utilizing the at least one indicator value; determining, bythe computer, a mean associated with the historical reserve airlinestaff demand information; and determining, by the computer, a standarddeviation associated with the historical reserve airline staff demandinformation.
 4. The method of claim 3, wherein the reserve staffinglevel comprises a set of reserve staff members, and wherein theoptimizing, by the computer, the reserve staffing model to generate thereserve staffing level operates bounded by the following rules: eachreserve staff member can work for at most 18 days in the first timeperiod; each reserve staff member must have at least 4 consecutive daysoff in the first time period; and each reserve staff member can beassigned to at most 6 consecutive working days.
 5. The method of claim3, wherein the optimizing further comprises: evaluating, by thecomputer, a risk of flight cancellation arising from the daily reserveairline staff demand level exceeding a reserve airline staffing level;and evaluating, by the computer, a financial impact of a flightcancellation arising from the daily reserve airline staff demand levelexceeding a reserve airline staffing level.
 6. The method of claim 3,wherein the determining a regression model utilizes a plurality ofindicator variables, and wherein the plurality of indicator variablesare configured with a dominant relationship.
 7. The method of claim 6,wherein the plurality of indicator variables comprise informationassociated with at least one of a peak day, a transition day, a weekend,a shoulder weekday, a summer month, or a shoulder-fall month.
 8. Themethod of claim 6, wherein the plurality of indicator variables comprisea peak day, a transition day and a weekend, wherein the peak day isdominant over the transition day and the weekend, and wherein thetransition day is dominant over the weekend.
 9. The method of claim 1,further comprising: reducing, by the computer, a number of reserve staffbased at least in part on the reserve airline staffing level; andutilizing the reduced number of reserve staff to service reservestaffing needs for each day in the first time period.
 10. The method ofclaim 1, further comprising varying, by the computer, a risk variableassociated with the first day in the first time period in order tomodify a risk variable associated with a second day in the first timeperiod, wherein the risk variable represents a likelihood of the reserveairline staffing level exceeding the reserve airline staff demand on thefirst day.
 11. The method of claim 10, wherein the varying the riskvariable associated with the first day comprises increasing a level ofacceptable risk associated with the first day.
 12. The method of claim10, wherein the varying the risk variable associated with the first daycomprises decreasing a level of acceptable risk associated with thefirst day.
 13. The method of claim 1, wherein the probabilistic reservestaffing model is formulated as:${\min\mspace{14mu}{Cost}} = {\sum\limits_{j \in P}x_{j}}$ subject to$\begin{matrix}{{P( {{\sum\limits_{j \in P}{A_{jt}x_{j}}} \geq d_{t}} )} \geq {\alpha_{t}\mspace{14mu}{\forall{t \in {T\mspace{14mu}{and}}}}}} \\{x_{j} = \{ {\begin{matrix}1 & {{if}\mspace{14mu}{pattern}\mspace{14mu} j\mspace{14mu}{is}\mspace{14mu}{included}\mspace{14mu}{in}\mspace{14mu}{the}\mspace{14mu}{solution}} \\0 & {otherwise}\end{matrix}\mspace{14mu}{\forall{j \in P}}} }\end{matrix}$ and where: ∝_(t) represents the minimum probability thatthe selected reserve pattern will exceed the predicted daily reserveairline staff demand level, C_(j) represents the financial cost ofselecting the reserve pattern j as part of the selected solution, C′_(t)represents the financial cost of having the insufficient reserve crewsto cover the scheduled set of airline flights in the first time period,t represents a day in the first time period, x_(j) represents a binarydecision variable to include reserve pattern j as part of the selectedsolution, and A_(jt) represents the mapping coefficient configured torelate the reserve pattern j to the corresponding day tin the first timeperiod.
 14. The method of claim 1, wherein the optimizing comprises:determining, by the computer, an unsatisfied demand cost associated withthe reserve airline staff demand exceeding the reserve airline staffinglevel on the first day in the first time period; determining, by thecomputer, an excess airline staffing cost associated with the reserveairline staffing level exceeding the reserve airline staff demand on thefirst day; and weighting, by the computer, the unsatisfied demand costand the excess airline staffing cost to determine whether to modify thereserve airline staffing level on the first day.
 15. The method of claim1, wherein: the reserve airline staffing level comprises a set ofreserve airline staff members, the first day is a peak day, the secondday is a non-peak day, and the modifying the reserve airline staffinglevel for the first day and the varying the risk variable associatedwith the second day are accomplished with a fixed number of reserveairline staff members.
 16. The method of claim 1, further comprisingimplementing, by the computer, the reserve airline staffing level bystaffing an airline flight with a reserve staff member in place of aregularly scheduled airline staff member.
 17. The method of claim 1,wherein the tuning includes placing frequently used files on separatefile systems to reduce in and out bottlenecks; sorting, by the computer,the reserve airline staffing level according to a known order tosimplify a lookup process; and obtaining, by the computer, the reserveairline staffing level from the database.
 18. A method comprising:forecasting, by a computer, a first predicted daily reserve airlinestaff demand level for each day in a first time period, wherein thefirst predicted daily reserve airline staff demand level for each day isgenerated based on a mean and a standard deviation of historical reserveairline staff demand level for that day, a minimum probability that aselected reserve pattern will exceed the first predicted daily reserveairline staff demand level, a financial cost of selecting a reservepattern as part of a selected solution, a financial cost of havinginsufficient reserve crews to cover a scheduled set of airline flightsin the first time period and a mapping coefficient configured to relatethe reserve pattern to a corresponding day in the first time period;storing, by the computer, the first predicted daily reserve airlinestaff demand level in a database; tuning, by the computer, the databaseto optimize performance of the database; designating, by the computer,the first predicted daily reserve airline staff demand level as a keyfield in a plurality of related data tables to speed searching for data;linking, by the computer, the plurality of related data tables based onthe type of the first predicted daily reserve airline staff demand levelin the key field; optimizing, by the computer, a risk-based solution tomeet the first predicted daily reserve airline staff demand level foreach day in the first time period, wherein the optimizing includesassigning airline staff members to on-duty days and reserve days, andwherein the optimizing includes staffing an airline flight with anairline staff member assigned to a reserve day in place of an airlinestaff member assigned to an on-duty day; evaluating, by the computer,the performance of the risk-based solution against an actual dailyreserve airline staff demand level for each day in the first timeperiod; and utilizing, by the computer, the performance of therisk-based solution during the first time period to create a secondpredicted daily reserve airline staff demand level for each day in asecond time period.
 19. The method of claim 18, wherein the forecastingcomprises: preparing, by the computer, a subset of historical open dutyperiods (ODPs) and block time data based on specified filters;assigning, by the computer, a plurality of indicator variables to eachday in the first time period, wherein at least two of the plurality ofindicator variables are configured with a dominant relationship;fitting, by the computer, a linear regression model of the historicalODP as a function of the block time data and the plurality of indicatorvariables, wherein the results of the linear regression model comprisecoefficients for the block time data and for each indicator variable;and utilizing, by the computer, the linear regression model to estimatethe mean and standard deviation of each of the historical ODPs.
 20. Themethod of claim 18, wherein the forecasting utilizes a probabilisticreserve staffing model formulated as: subject to${\min\mspace{14mu}{Cost}} = {{\sum\limits_{j \in P}\;{C_{j}x_{j}}} + {\sum\limits_{t \in T}\;{C_{t}^{\prime}( {{1 -} \propto_{t}} )}}}$and${{\sum\limits_{j \in P}\;{A_{jt}x_{j}}} - {F^{- 1}( {1 - \alpha_{t}} )}}\mspace{14mu} \geq {0\mspace{14mu}{\forall{t \in {T \propto_{t} \geq \propto_{\min}\mspace{14mu}{\forall{t \in \mspace{14mu}{and}}}}}}}$$x_{j} = \{ {\begin{matrix}1 & {{if}\mspace{14mu}{pattern}\mspace{14mu} j\mspace{14mu}{is}\mspace{14mu}{included}\mspace{14mu}{in}\mspace{14mu}{the}\mspace{14mu}{solution}} \\0 & {otherwise}\end{matrix}\mspace{14mu}{\forall{j \in P}}} $ where: ∝_(t)represents the minimum probability that the selected reserve patternwill exceed the first predicted daily reserve airline staff demandlevel, C_(j) represents the financial cost of selecting a reservepattern j as part of the selected solution, C′_(t) represents thefinancial cost of having the insufficient reserve crews to cover thescheduled set of airline flights in the first time period, t representsa day in the first time period, x_(j) represents a binary decisionvariable to include reserve pattern j as part of the selected solution,A_(jt) represents the mapping coefficient configured to relate thereserve pattern j to the corresponding day t in the first time period,and F⁻¹(1−α_(t)) represents a nonlinear variable.